Self-descriptive Software Components

Many technical problems involved with Component Based Software Development might be considered solved these days. Less so are mental reservations both, developers as well as their managers have with respect to the risks involved with building software from powerful building blocks. This paper addresses the issue of trust developers might extend towards components. Besides psychological aspects this issue has a technical aspect. We will focus on the latter. After a brief review of mechanisms to describe software components and the relationships between descriptions and cer-tiications, the paper zooms in on \self-descriptive" methods, i.e. methods directly involved with the executional properties of software. The approach presented in detail is tuned towards ne-grained distinctions. It lends itself particularly to questions of version discrimination and software maintenance. 1 Motivation My great-grandfathers horse-cart found its way home, even when the old man was too tired to direct the horses. My car will kill me, if I fall asleep on the highway .-Can we build software that resembles rather my great-grandfathers horses than my car? We increasingly rely on complex technology in spite of the apparent deeciencies highlighted in the above sentence. Is there a chance to bring some of the reliability of these old systems back to modern technology, speciically to software, a technical artifact that is occasionally claimed to be \artiicially intelligent"? When aiming at such goals, we have rst to analyze some of the diierences between the system consisting of horse, cart, and driver as opposed to the system consisting of car and driver. Since we want to abstract from the driver and since the material the wagon or the car respectively are made of does not really contribute to this diierence, the distinction has to be found in the horse. The car is a system without a self 1. The combination horse and cart, however, has in the horse-part of this system at least some limited capability of recognizing its self as well as-in this example-the location of its self as opposed to the location where it ought to be in the evening. We better don't stress this analogy to a point were it breaks. However, we might at least agree that from a reliability perspective, a component knowing about its self has merits over a component that is just there without such knowledge. Let us pause at the proverb \To a person with a nail, any tool looks like a …